fix(gate): anchor current state on the project's main line, not the newest scan - #6

latest_succeeded_scan_id — the single resolver behind Overview, the project-list badges, the inventory and the build gate — ordered purely by recency. A project wired to CI on both main and release/1.x therefore resolved its current state to whichever branch finished last, and since evaluate_gate goes through the same function, main's pipeline could be blocked by a release branch's critical CVE. The write side already knew the branch (Scan.ref, normalized at scan-create); every read path ignored it.

The anchor now prefers a scan on the project's main line, ordering by that preference before recency: projects.default_branch when set, else main, and if neither matches any scan it falls through to the old project-wide rule. That fallback is what makes it safe — a project on trunk, or one whose scans are all ref-less ad-hoc runs, behaves exactly as before. The main guess matters because default_branch is NULL on ~97% of rows here; the create form never asks for it and the source pipeline clones the remote's own HEAD rather than passing --branch.

GET .../gate-result also takes ?ref= so a CI job can name its own branch instead of relying on the guess. It is exact: a branch with no succeeded scan returns the no-signal pass rather than borrowing another branch's findings. That required threading the ref into evaluate_gate as well — the router's resolved None means both "not pinned" and "that branch has nothing", and only the ref distinguishes them.

Eight integration failures and three unit failures showed up locally; all eleven reproduce unchanged on main (accumulated rows in my dev database, plus a disk-guard trip at 96.8% full), so none are from this change.